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ACCESS CONTROLr FOR MULTICAST CHAISINEIj REQUEST 
TECHNICAL FIELD OF THE INVENTION 

The present invention relates to methods and arrangements 
5 for access control in a multicast system when data is 
distributed from a source to at least two users. 



DESCRIPTION OF RELATED ART 

' — 

It is possible to send video over packet networks such as 
10 IP- and Ethernet networks. Since the packet stream needed to 
produce the moving pictures on the TV screen has 
considerable bandwidth, many networks do not have sufficient 
total bandwidth to provide for unique video data streams to 
each user. For TV programs viewed by several users 
15 (recipients) , it is sufficient to send one packet stream 
from the source, and duplicate this stream only at points in 
the network where there is more than one output port, which 
leads to a viewer. According to this scheme, any link 
between a recipient and the source carries exactly one copy 

2 0 of the packet stream. A link that is not between the source 

and a recipient does not carry the packet stream. This 
technique is called multicast. Multicast is a valuable way 
of saving bandwidth when data is to be sent to several 
recipients at the same time. 

25 In some multicast systems, control of which links the packet 
stream is copied to rests with the recipients. Data streams 
are addressed to rather abstract destination addresses. 
These addresses do not represent static sets of 
destinations. They are identification tags, which the users 

3 0 and the network use when negotiating about where streams are 

to be copied. These addresses are called multicast 
addresses. According to some protocols for negotiating about 
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multicast streams, sources send packets addressed with 
multicast addresses into the network. Other nodes become 
recipients of the multicast stream by requesting to be so. 
IGMP is a protocol for hosts on IP networks to negotiate 
5 with Ethernet switches over which multicast streams they are 
to receive. In some networks there are regions, which do not 
have sufficient resources to transfer all multicast streams, 
which nodes might request. This is reasonable since 
multicast is about handling large data streams. Or, put 

10 another way, if there was sufficient bandwidth for all data 
streams everywhere, there would not be a need for multicast. 
The hope of the builders of such networks is that requests 
will be sufficiently congruent (nodes near each other 
request the same multicast streams to some extent) for the 

15 users to be sufficiently satisfied. The resources that may 
be limited include total bandwidth and total number of 
streams . 

For the case when the network is not able to fulfill all 
requests for multicast streams there is need for an arbiter 
2 0 or resource disperser. A packet transmission apparatus is 
disclosed in the patent US 2003/0043840. A packet arbiter 
selects packets by a prescribed algorithm and requests 
transmission of the packet. The US patent describes a rather 
static system where current need are not taken mto 

2 5 consideration and where fairness is set aside. Since the 

load on a network is dependent on congruence of requests, 
the techniques used for resource allocation in the unicast 
case cannot be applied directly. In the unicast case, the 
load on the network can be calculated by adding the loads 
30 caused by individual users. In the multicast case, 
requesting a new stream adds the new stream to the load, 
while requesting a stream already being streamed to another 
user connected to the same network node adds little or 
nothing to the load on this node. Therefore the methods for 

3 5 limiting resource utilisation for unicast users cannot be 
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applied to multicast users with, reasonable efficiency. 
Bandwidth, limits sufficiently low to ensure that the system 
is not overloaded would result in severe underutilization of 
the network resources . 

5 

SUMMARY OF THE INVENTION 

The present invention solves problems related to resource 

conflicts in a multicast system. The problems are solved by 

the invention by limiting accessibility of bandwidth to 

10 users before resource conflicts occur. 

* 

More in detail the problems are solved by the invention by a 
method for access control in the multicast system when data 
is distributed from a source to users on a common link via a 
node. The node comprises a request arbiter arranged to 
15 select data from the source to the users. The method 
comprises the following steps : 

Assigning a weight to each user associated with 
the node, which weights determine each user's 
allowed bandwidth i.e. bandwidth allowed to use 
2 0 out of available bandwidth on the common link. 

Receiving a request to join a multicast session, 
from a user to the node. 

Comparing in the node, actual bandwidth usage by 
the user calculated as the sum of the user's 
25 bandwidth part of each used session on the common 

link including the new request, with the users 
allowed bandwidth. 



An advantage of the invention is that denial of access 
3 0 affects heavy users as a limitation of how much multicast 
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information they get access to rather than affecting users 
who are trying to go from no information to some 
information. This means a higher probability of success for 
users who are trying to get their first channel at the cost 
5 of users getting a lower probability of viewing many 
channels . 

Another advantage is that a higher niomber of channels are 
made available for those who view channels, which are also 
viewed by others. Thus, the ability to load the distribution 
10 network is evened out. Users get more equal opportunities. 
Or rather, the operator gets control over the opportunities 
the viewers get to load the network. 

The invention will now be described more in detail with the 
aid of preferred embodiments in connection with the enclosed 
15 drawings . 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a block schematic illustration of a multicast 
communication system used to transfer data from a video 
2 0 source via a request arbiter to users at a destination. 

Figure 2 discloses a table in which users subscribing to 
different sessions are shown. 

Figure 3 discloses a flowchart illustrating a method to 
prevent resource conflicts in a multicast system. 

25 Figure 4 shows a block schematic illustration of a multicast 
communication system used to transfer data from a video 
source via request arbiters to users at a destination. 

Figure 5 discloses a block schematic illustration of a 
branch node . 



30 
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DETAILED DESCRIPTION OF EMBODXiyiENTS 

In figure 1 a multicast transmission system for video 
transfer is disclosed in a first embodiment. The 
transmission system transmits and distributes video 
5 sequences from a video source VS to several users U1-U9 6. 
The users, that are receivers or local distributors of video 
sequences, are symbolized with boxes in figure 1 but for the 
sake of clarity of figure 1, only the users Ul, U2 , U12 , U85 
and U96 are shown in the figure. The multicast system 

10 comprises a source network part 3, an access network part 
AN, and a destination network part DEST. The access network 
AN, is a packet transmission network that can be of the type 
connection oriented or connectionless. The source is in this 
example a video source VS and the destination consists of 

15 different users U1-U9 6 located in for example offices or 
homes. In this example ninety-six users divided into groups 
of twelve are connected to different branch nodes BN21-BN28 
in the access network, i.e. twelve users are connected to 
each branch node. The access network AN comprises Ethernet 

2 0 switches ESI and ES2 that distribute data between the source 

VS and the branch nodes BN21-BN28. A first link Ll connects 
the video source VS to the Ethernet switch ESI, a second 
link L2 connects the Ethernet switch ESI to the Ethernet 
switch ES2 and a third link L3 connects the Ethernet switch 
25 ES2 to a branch node BN21. 200 video sessions are available 
from the video server VS. The third link L3 , which also is 
called a common branch node link L3 is a 10 0Mbit /s link. The 
branch node BN21 is a MUX-unit that distributes data 
arriving at the node to the users U1-U12, via SMbit/s ADSIi- 

3 0 links. The user Ul is a distributor in a home to which a TV 

and a PC are connected. The branch node BN21 comprises a 
request arbiter ARB. The arbiter considers all currently 
granted bandwidth requests, the contracted conditions for 
all users U1-U12 and available resources . From these facts 
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the arbiter determines for each request whether it should be 
granted or not. This will be further explained below. 

According to the invention, each user is assigned a weight 
to determine how much multicast bandwidth each user is to be 
5 allowed to receive. The weight is assigned when the system 
is configured. Bandwidth availability is hereby proportional 
to weight assigned. The weight assigned is translated into 
the bandwidth available to the user, i.e. the allowed 
bandwidth, by using a conversion factor that decreases with 
10 actual load on the third link L3 . 

A user's actual bandwidth on a link is calculated as the sum 
of the users share in all the sessions subscribed to. If the 

user is subscribing to sessions 5'|,»S2...5',^ / the number of 
subscribers to these sessions is n^^n2^'Jt,n and the bandwidths 
15 are b^^b^.,,b^^ respectively. The users actual bandwidth is the 
sum of bJm for all those sessions. 

' Figure 2 discloses a table of users U1-U12 in relation to 
subscribed sessions on the third link L3 out of the two 

hundred sessions S^—S^q^* As already said, the third link is 

20 a 100 lyDoit/s link. In this example a bandwidth of 50 ]yLbit/s 
is reserved for the subscribed sessions. In figure 2 it can 

be seen that Ul has subscribed to sessions S^^S^.S^^ and that 

U6 subscribes to sessions S^^S^^ . In this example each 

subscribed session requires l,5Mbit/s out of the reserved 50 
25 Mbit/s bandwidth on the link L3 . In figure 2 it can be seen 
that seventeen different sessions occupy the third link L3 
and consequently 50— 17 jcl. 5 = 24,5Mbit /s remains available on the 
third link. This is the so-called available bandwidth. 

A method according to the invention will now be explained. 
30 The method comprises the following steps: 
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When the system is configured each user is 
assigned a weight. The weight settles the 
importance of the user. In this example, the users 
U2-U6 have been assigned the weight '^1" , U7-U12 
5 are assigned the weight ^"2", U13~U18 are assigned 

the weight '^3'' and U19-U24 have been assigned the 
weight ^'4". The user Ul has been assigned the 
weight "3". The weight ^'1" means in this example 
that the user is allowed to use 2 0% of the third 
10 link's L3 remaining bandwidth, '^2" means 15%, '^3" 

means 10% and ^^4" means 5%. 

. A request to join a session is received to the 
branch node BN from the user Ul . Ul requests to 

join the session S^i . The arbiter ARB21 starts to 

15 determine Ul's actual, bandwidth. As can be seen in 

figure 2, Ul is already part of the sessions S^^S2 

and S^^ . Ul alone uses the session while Ul 

shares ^2 with eight other users and S^-y with two 

other users. Session S^^ is before Ul's request 

2 0 already shared by two other users U8 and U12 . As 

said, each session requires l,5Mbit/s bandwidth 
and Ul's actual bandwidth is hereby calculated as 
the sum of Ul's bandwidth part of each used 
session, including the new request, i.e. 

25 Kj^K^bL= M+M+M = 2,167 Mbit/s plus the 

/Ij ^51 19 3 

bandwidth part of the new requested session S^^ , 

b 15 

which is --^= -^ = 0,5 Mbit/s. Ul's actual bandwidth 

3 

is hereby 2,167 + 0,5 = 2,667 Mbit/s. 

The arbiter determines available bandwidth. In 

3 0 figure 2 it can be seen that seventeen sessions 
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are reserved on the third link L3 . This means that 
a bandwidth of 50-17x1,5 Mbit/s is available on 
the third link L3 , i.e. 24,5 Mbit/s is available. 

The arbiter determines bandwidth available to Ul, 
5 i.e. the allowed bandwidth. The allowed bandwidth 

is calculated as available bandwidth on the link 
L3 in relation to Ul ' s weight . The weight 
determines what relative share of the bandwidth 
reserved for this kind of sessions the user is 

10 entitled to. The bandwidth made available to the 

user is hereby proportional to the weight assigned 
to the user. In this example, Ul ' s weight is "3" 
i.e. Ul is allowed to use 10% of the available 
bandwidth. Ul ' s allowed bandwidth is hereby 

15 0,1x24,5 = 2,45 Mbit/s. 

The arbiter compares Ul's actual bandwidth 
2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s 
and finds that allowed bandwidth is lower than 
ac tual bandwidth . 

20 - The arbiter denies the request from Ul . 

Different scenarios will now be conceived to highlight the 
advantages of the invention. For example: 

Assuming that available bandwidth on the third 
l^nk Xj3 is more than the 24,5 Mbit/s i.e. that 
less users have subscribed to the sessions. Let's 
assume that the available bandwidth is 3 0 Mbit/s. 
Ul's weight is ^'3" i.e. Ul is allowed to use 10%. 
This in turn will lead to a situation where the 
arbiter compares Ul's actual bandwidth 2,667Mbit/s 
with Ul's allowed bandwidth 3,0 Mbit/s and finds 
that allowed bandwidth is higher than actual 



25 



30 
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bandwidth. Consequently the arbiter will allow the 
request from Ul . 

Again returning to the original example and 
assuming that Ul has been weighted as a more 
5 important user and instead of weight ^^3" have got 

weight '^2" i.e. Ul is allowed to use 15%. This 
will lead to a situation where Ul ' s allowed 
bandwidth is 0,15x24 = 3,6 Mbit/s. This in turn will 

lead to a situation where the arbiter compares 
10 Ul's actual bandwidth 2 , 667]yibit/s with Ul's 

allowed bandwidth 3,6 Mbit/s and finds that 
allowed bandwidth is higher than actual bandwidth. 
Consequently the arbiter wi 11 all ow the request 
from Ul . 

15 - Again returning to the original example and 

assuming that Ul for the first time requests to 
join a session. In this case Ul's actual bandwidth 

15 

will be -^ = 0,5 Mbit/s instead of the earlier 

3 

2,167 + 0,5 = 2,667 Mbit/s. This in turn will lead to a 

2 0 situation where the arbiter compares Ul's actual 

bandwidth 0,5 Mbit/s with Ul's allowed bandwidth 
2,45 Mbit/s and finds that actual bandwidth is 
lower than allowed bandwidth. Consequently the 
arbiter will allow the request from Ul . 

25 - Again returning to the original example and 

assuming that Ul is the first subscriber 

requesting to join the session S^-^ . In this case 

1,5 

Ul's actual bandwidth will be 2,1674 — ^ = 3,667 

1 

Mbit/s. Compare if Ul instead was the tenth user 

3 0 to join the session So.. In this case Ul's actual 
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bandwidth would be 2,167 + — = 2,317 Mbit/s. When 

10 

comparing the two scenarios it can be seen that 
the arbiter will allow the request when Ul is 
number ten but deny the request if Ul is number 
5 one . 

Let's assume that the requested session S^i was already used 

by someone ells. This is actually the case with the 

requested session S^^ in the above first embodiment- In this 

case the new request will not imply any additional load and 
10 the user Ul may be allowed to use the session even if not 
actually justified. The method according to this variation 
of the first embodiment will enable this, and comprises the 
following further steps after the arbiter has compared Ul ' s 
actual bandwidth 2,667Mbit/s with Ul ' s allowed bandwidth 
15 2,45Mbit/s (compare the method in the first embodiment): 

The arbiter ARB21 finds out that the requested 

session S^^ already is used by at least one other 

user U8,U12. This information is stored in a 
memory in the arbiter ARB21. 

2 0 - The arbiter allows the request from Ul . 

Now again returning to the first embodiment. Let's assume, 
as yet another variation of the first embodiment that the 

user wants to return back to session S^^ after for example a 

25 short TV- commercial break. The user is hereby seen as 
subscribing to the session also for some time after the 
actual subscription has ended. For a period of time after 
the actual subscription has ended, the user is guaranteed to 
be able to ^'come back" . The operator sets a so-called 

30 qualification time that defines '"short". If the user would 
not be allowed to return after a short commercial break it 
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would cause dissatisfaction. The method according to this 
variation of the first embodiment comprises the following 
further steps after the arbiter has compared Ul's actual 
bandwidth 2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s 
5 (see the method in the first embodiment) : 

The arbiter ARB21 finds that the user Ul used the 

session S^^ a time ago that is less than the 

predefined qualification time. This information is 
stored in a memory in the arbiter ARB21. 

0 - The user's weight is temporarily changed from ''3" 

to ''2", i.e. the user has become a more important 
user. 

The arbiter allows the request from Ul . 

When the user later leaves the session, the user's 
5 weight will again be changed back to ''3". 

In order to prevent that quick browsing through sessions 
accumulate extra subscriptions that cause the arbiter to 
deny subscriptions, there is a need to filter out very short 
actual subscriptions. The operator hereby defines a so~ 

0 called guarantee time that defines the time a user must stay 
at a session in order to later be allowed to come back to 
the session. This means a variation of the method above 
whereby the arbiter also checks the guarantee time after 
having checked the qualification time. The weight will 

5 hereby be changed from ^'3" to ''2" only if the user actually 
used the session a time ago that is less than the predefined 
qualification time and if the user at that time used the 
session during a time period that exceeds the predefined 
guarantee time. 

0 In figure 3 the most essential steps of the method can be 
seen. The flow chart is to be read together with the earlier 
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shown figures . The method according to the invention 
comprises the following steps: 

When the system is configured each user is 
assigned a weight. The user Ul has been assigned 
5 the weight ''3". This step can be seen in the flow 

chart by a block 101. 

- A request to join a session is received to the 
branch node BN from the user Ul . Ul requests to 

join the session S^^ . This step can be seen in the 

10 flow chart by a block 102 . 

The arbiter ARB21 determines Ul ' s actual 
bandwidth- Ul's actual bandwidth is hereby 
2,167 + 0,5 = 2,667 Mbit/s. This step can be seen in the 
flow chart by a block 103 . 

15 - The arbiter determines available bandwidth on the 

third link L3 . A bandwidth of 50-17x1,5 Mbit/s is 
available, i.e. 24,5 Mbit/s is available. This 
step can be seen in the flow chart by a block 104. 

The arbiter determines Ul's allowed bandwidth. 

20 Ul's allowed bandwidth is 0,1x24,5 = 2,45 Mbit/s. This 

step can be seen in the flow chart by a block 105 . 

The arbiter compares Ul's actual bandwidth 
2,667MDit/s with Ul's allowed bandwidth 2,45Mbit/s 
and finds that allowed bandwidth is lower than 

2 5 actual bandwidth. This step can be seen in the 

flow chart by a block 106. 

The arbiter denies the request from Ul. This step 
can be seen in the flow chart by a block 107 . 

A second embodiment is disclosed in figure 4. The figure 

3 0 shows the same multicast system as was disclosed earlier in 
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figure 1. In this example not only the third link L3 is 
considered to be a critical link regarding conflicts . There 
is also a potential risk for conflicts in the second link 
Li2 . The second link is a lOOMbit/s link and is called a 
5 common Ethernet link Li2 . Also the Ethernet Switch ES2 
comprises in this embodiment a request arbiter ARB2 • This 
second embodiment is a continuation of the first embodiment 
but it is assumed that the arbiter ARB21 did not deny the 
previous request from Ul due to for example that user Ul was 

10 weighted ^^2" in accordance with the earlier discussed 
scenario. When the system was configured each user 
associated with the Ethernet Switch was assigned a weight, 
Ul waS/ as mentioned, assigned the weight '"2", U2-U12 were 
assigned the weights as said in the first embodiment while 

15 the users U13-U9 6 all were assigned the weight ^'1". The 
method according to the invention, in the second embodiment 
comprises the following further steps: 

After ARB21 has allowed the request from Ul, Ul ' s 
request to join the session S^^ is forwarded from 

2 0 the branch node BN21 to the Ethernet Switch ES2 . 

The arbiter ARB2 in the Ethernet Switch ES2 
determines Ul ' s actual bandwidth on the second 

link L2 . Ul is already part of the sessions S^,S2 
and S^^ . These sessions are shared on the second 

25 link also by some of the users U13-U9 6- Ul^s 

actual bandwidth is hereby in this example assumed 
to be 1,5 Mbit/s, 

The request arbiter ARB2 now determines available 
bandwidth on the second link L2 . In this example 

3 0 it . is assumed that a bandwidth of 3 Mbit/s is 

available on L2 . 
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The arbiter determines Ul's allowed bandwidth. 
Ul's weight is ^^2" (15%) and Ul's allowed 
bandwidth is consequently 0,15x3 = 0,45 Mbit/s. 

The arbiter compares Ul's actual bandwidth 1,5 
5 Mbit/s with Ul's allowed bandwidth 0,45 Wolt/s and 

finds that allowed bandwidth is lower than actual 
bandwidth . 

The arbiter ARB2 denies the request from Ul . 

The Ethernet Switch ES2 sends a deny-message to 
1 0 the branch node BN2 1 . 

The request arbiter ARB21 in the branch node BN21 
also denies the request from Ul and hereby frees 
capacity on the third link L3 . 



15 In figure 5, the branch node BN21 is disclosed 
schematically. The node comprises a MUX-unit MU that 
distributes data from the third link L3 to the different 
ADSL links ADSL-1 . The node also comprises the request 
arbiter ARB21 that comprises a central unit CU and two 

20 memory spaces MEMl and MEM2 . MEMl comprises the table 
disclosed in figure 2 , MEM2 comprises information about 
which users have recently left a requested session. The 
central unit CU fetches information from the third link, the 
ADSL links and the memory spaces . CU process the 

25 information, calculate bandwidths and times, controls the 
MUX-unit and distributes selected sessions from the third 
link L3 to the ADSL links . 

Different variations are of course possible within the scope 
of the invention. The arrangement in figure 5 can for 
3 0 example be built up differently as long as the functions 
according to the invention remain. A users weight can be re- 
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assigned at any time. Bandwidth, occupied by a session may be 
fixed or may vary. The invention is in other words not 
limited to the above described and in the drawings shown 
embodiments but can be modified within the scope of the 
5 enclosed claims. 



